Could you check if the morphe window looks decent on windows now?

I don't use Windows but maybe someone else can check:

https://github.com/MorpheApp/morphe-cli/suites/63221859474/artifacts/6259679436

Oh wait, are you on Linux? How does it look on that?

I'm on Mac. It looks good for me.

oh lmao, I am on mac too. It looks decent on mac, but the second I switch to my windows laptop, the colors look a bit washed. I don't if it's a colors issue or my screen issue.

Does this look too washed out? The contrast is much better, but I kinda feel it lacks emotion. Feels like strawberry syrup. But what do you think?

what if the grey text is black, and the red is white or black?

See how the Supported apps section looks now. What are your opinions on it? Please tell me your ideas to improve it, if you have any.

I think it looks great. I like the fixed width font that gives off a console vibe.

Picking an experimental version shows a "this may not work" warning but it can instead show a 🧪 experimental warning message (can use same message shown in Manager).

Details

The console output of the GUI is so much easier to read when the patch is displayed last:

Patch applied: Hide video action buttons
Patch applied: Loop video
Patch applied: Miniplayer
Patch applied: Navigation bar
Patch applied: Open Shorts in regular player
Patch applied: Open links externally
Patch applied: Open videos fullscreen
Patch applied: Playback speed
Patch applied: Remove background playback restrictions
Patch applied: Remove viewer discretion dialog
Patch applied: Restore old search filters
Patch applied: Return YouTube Dislike
Patch applied: Sanitize sharing links
Patch applied: Seekbar
Patch applied: Shorts autoplay
Patch applied: SponsorBlock
Patch applied: Spoof app version
Patch applied: Spoof device dimensions
Patch applied: Spoof video streams
Patch applied: Swipe controls
Patch applied: Theme
Patch applied: Video ads
Patch applied: Video quality

Compared to CLI:

INFO: "Check watch history domain name resolution" succeeded 
INFO: "Copy video URL" succeeded 
INFO: "Custom branding" succeeded 
INFO: "Custom player overlay opacity" succeeded 
INFO: "Disable DRC audio" succeeded 
INFO: "Disable QUIC protocol" succeeded 
INFO: "Disable Shorts resuming on startup" succeeded 
INFO: "Disable double tap actions" succeeded 
INFO: "Disable haptic feedback" succeeded 
INFO: "Disable layout updates" succeeded 
INFO: "Disable player popup panels" succeeded 
INFO: "Disable rolling number animations" succeeded 
INFO: "Disable sign in to TV popup" succeeded 
INFO: "Disable video codecs" succeeded 

I think the CLI console could be changed to use the same 'patch last' format of:

INFO: Success: Check watch history domain name resolution
INFO: Success: Copy video URL
INFO: Success: Custom branding
INFO: Success: Custom player overlay opacity
INFO: Success: Disable DRC audio
INFO: Success: Disable QUIC protocol
INFO: Success: Disable Shorts resuming on startup
INFO: Success: Disable double tap actions
INFO: Success: Disable haptic feedback
INFO: Success: Disable layout updates
INFO: Success: Disable player popup panels
INFO: Success: Disable rolling number animations
INFO: Success: Disable sign in to TV popup
INFO: Success: Disable video codecs

I don't use Windows but maybe someone else can check:

https://github.com/MorpheApp/morphe-cli/suites/63221859474/artifacts/6259679436

I don't use Windows but maybe someone else can check:

https://github.com/MorpheApp/morphe-cli/suites/63221859474/artifacts/6259679436

i was report this on the Reddit a day ago use this version
https://github.com/MorpheApp/morphe-cli/actions/runs/23846854173/artifacts/6219563344

patch version: 1.23.0-dev.8
YouTube version: 21.14.482

@eksan127 Sorry that was the old build. Try this:
https://github.com/MorpheApp/morphe-cli/suites/63516598277/artifacts/6293794474

Picking an experimental version shows a "this may not work" warning but it can instead show a 🧪 experimental warning message (can use same message shown in Manager).

Yea, will change this.

I think the CLI console could be changed to use the same 'patch last' format

Roger that

@eksan127 Sorry that was the old build. Try this: https://github.com/MorpheApp/morphe-cli/suites/63516598277/artifacts/6293794474

@prateek-who patching work but output file still have all architecture

Will look into this

@wchill Had a small confusion.

When a user passes --striplibs, we pass it using keepArchitectures right. The patcher does its job, and when it gets to the lib stripping part, it does it correctly on its temp directory. It properly deletes the unwanted arch dirs from disk, and even logs "Stripped N lib files". This is good.

But here's the issue now. The way the engine rebuilds the output APK is by copying the original input APK and then applying PatcherResult.applyTo() to splice in the changes. applyTo() only knows what to delete from the rebuilt zip via ResourceCoder.getDeletedFiles(). And in ArsclibResourceCoder that method is currently a hard-coded no-op:

    /**
     * No-op, not currently supported by ArsclibResourceCoder.
     */
    override fun getDeletedFiles(): Set<String> = emptySet()

The deletion set handed to applyTo() is always empty. And that means no libs get stripped. Unless I am reading this wrong (which also could be true), this is the issue right now. Could you check if this is true? Or if there is some issue on my end in this PR? (Because I messed up earlier and had to solve a lot of conflicts, so there could be chances that maybe something changed during my merge fest.)

It's a no-op because we already delete the files on disk. So there's no need to delete them in the later step.

At least, that's how it's supposed to work.

Is the manager using the keepArchitecture form the patcher? If yes, then how is it doing that properly?

I tested --striplibs on v1.6.4-dev.2 and v1.6.4-dev.1, and striplibs seems broken on all of them. It seems to be broken ever since dev.1. The stable v1.6.3 strips libs perfectly. Here's how to test it:

1. Run the patching with the above mentioned cli versions. Add --striplibs and whatever cpu arch at the end. I tested with arm64-v8a
2. Check the resultant apk's size. Could also run this command: unzip -l patched_app.apk | grep '^.*lib/' | awk '{print$4}' | cut -d/ -f1-2 | sort -u

This should show the archs present. Could you check once too. I could've made a mistake, but it seems broken.

This is where the stripping happens: https://github.com/MorpheApp/morphe-patcher/blob/dev/src/main/kotlin/app/morphe/patcher/resource/coder/ArsclibResourceCoder.kt#L220

I don't have time to investigate this for the next few days, but you could set a breakpoint there and see what is happening on the file system to debug.

Did the line 220 check via the filesystem instead of a debugger.
Checking: patched-temporary-files/patcher/apk/root/lib/
gave me:arm64-v8a

stripNativeLibraries() is working correctly. The libs are being stripped. The bug is most likely with the applyTo() method. Ran it with AI and this is what it says:
"So stripNativeLibraries() at L220 works perfectly — armeabi-v7a, x86, x86_64 are gone from the scratch dir. The bug is downstream: applyTo() builds the output APK as originalApk.copyTo(rebuilt); applyTo(rebuilt) and only removes entries reported by getDeletedFiles(), which is currently = emptySet() in ArsclibResourceCoder.kt:356. So the original APK's lib entries get carried straight through into the output, and the on-disk strip is invisible to applyTo()."

Honestly we shouldn't be copying the original APK anyway for arsclib because all of the resources are already being repacked.

Feel free to send a PR to fix this. Easy fix is you can populate the set returned by getDeletedFiles() by modifying detectFileChanges to also record deleted files, harder fix is to redo the APK repacking.

Sure thing, will submit a PR using your easy approach. I asked claude what the harder fix would be and I've been trying to make sense of its explanation for 30 mins now. From what I understand, we would have to rework how the patcher assembles the final APK. Currently it's built by copying the original and applying a diff, and the harder fix seems moves to packing it from scratch out of the working dir. It makes some sense on the surface but I don't seem to understand how it is going to work. Seems like the right long term direction, but maybe we do that in the future.

Conceptually it's just taking the resources.apk and adding the dex files, which I think should work but is likely to have edge cases. So it's safer to just go with the deleted files approach.

There is one small issue that needs your input Liso. I wanted to customize titleBarInset to give the window a polished, edge-to-edge look. Initially it felt impossible, but eventually I managed to make it work with JetBrains Runtime. This JRE gives access to control the title bar insets.

Now, this is works flawlessly in dev, because the toolchain pulls JBR in automatically, however, in reality, people generally use OpenJDK, Temurin, Zulu, etc, none of which expose the JBR title bar apis and this is where this breaks. The title bar looks ugly. We lose the ability to control them.

We have two possible solutions:

1. Chuck this idea and let it go. We simply use a standard decorated window everywhere. Kinda meh and mid looking.
2. We could instead detect JBR at startup.
   a. If JBR detected, use the polished custom title bar
   b. If no JBR, fall back to a standard decorated window with zero insets

However, with this option, we'll also have to urge the users to use JBR in the documentation. What do you think?

If it doesn't easily work with a simple Zulu/OpenJDK install, then we could chuck it. It's only for visual appearance and I don't think it's worth asking the user to do extra steps.